「セキュリティ・キャンプ2020オンライン」と「とある診断員とSecurity-JAWS#02」で行った講義の資料を共有しつつ振り返ってみた

こんにちは、臼田です。

みなさん、AWS環境のセキュリティ維持してますか？(挨拶

今回は最近実施した以下の2つのイベントの資料を共有しつつ、いろいろ振り返ってみたいと思います。

セキュリティ・キャンプ全国大会2020オンライン - なぜ、Webサイトは乗っ取られたのか？AWS環境における実践的なインシデントレスポンス

とある診断員とSecurity-JAWS#02 - connpass

資料

私の担当した前半のパートの資料です。内容は一般向けになるようにアレンジしていて、とある診断員の方に寄せています。

後半パートの資料や「どんな観点で攻撃シナリオを作ったのか」という部分については担当された洲崎さんによって以下にまとめられていますので合わせてご参照下さい。

AWS環境における実践的なインシデントレスポンス演習の作成 | 調査研究/ブログ | 三井物産セキュアディレクション株式会社

振り返り

今回のイベントではAWS環境におけるインシデントレスポンスを行うという課題を用意しました。

AWSのセキュリティを学習するためのコンテンツとしては、有名なところではflaws.cloudやCloudGoatなどがありますが、これらはどちらかというと攻撃者側からセキュリティを学ぶものでした。

今回のコンテンツはこれらとも違い、1つの環境における複数の攻撃がつながって最終的にAWS環境のAdministrator権限が奪取される一連のシナリオがあり、攻撃が一通り成功してしまった(とんでもない被害が起きてしまった)環境を調査することにより、単純にAWSのセキュリティを学ぶだけではなく、インシデントレスポンスの考え方や、実際のAWS上のセキュリティツールを駆使してその調査を行うことに主眼を当てています。

この攻撃シナリオの部分は上述の通り洲崎さんの記事をご確認下さい。

想い

このイベントを企画するにあたり、特にAWS環境のセキュリティはいいものだぞ！ということを伝えたいと想って取り組みました。

AWS環境のセキュリティ事故は何かと話題になりやすく、情報漏えいが起きたとか多額の請求が来たとかいろいろあります。

一方で、そもそもAWSを利用することによる素晴らしいセキュリティ上のメリットや、実際のその機能に触れられる機会は少ないと思います。それはいくつか要因があると思いますが、一つはコンテンツにしづらいところだと思います。

セキュリティを学ぶために、一般的なやられ環境と呼ばれる脆弱な学習環境を提供している方たちには頭が上がりません。いっぱい勉強させてもらっています。

AWS上では実際の攻撃を体験するための脆弱な環境は、なかなか維持することは難しく、きめ細かい権限の調整や環境の分離により一部の内容が公開できます。その点を確立しているflaws.cloudはめちゃくちゃすごいです。

CloudGoatは自身のAWS環境にアクセスを絞った形で脆弱な環境を展開できるツールです。EasyなレベルのIAM権限の設定漏れへの攻撃や、もっと難しいEC2やその他のリソースと連携した攻撃を体験することができる環境をTerraformを使って簡単に展開できることが魅力です。

ただこれらのコンテンツでは、あまり攻撃を受ける側の体験はできません。

実際に攻撃が起きた際にはどのようなログが残るでしょうか？アプリケーションに残るログは？CloudTrailにはどのように記録される？AWS Configは？

各種セキュリティ機能はどう動くでしょう？AWSからの連絡は？GuardDutyは？

調査はどのようにするでしょうか？Detectiveではどう見れる？Athenaでログはどう見れる？EC2はいつ起動した？その設定はいつ変更された？

AWS特有の確認ポイントもありますし、AWS特有の便利なところもあります。

普段からAWS環境の構築や運用、あるいはインシデントレスポンスに関わっている立場から、可能な限りそのような要素を伝えたいと想って作りました。

リアリティのある環境

私の方ではこの環境を用意するにあたり、「よりリアリティのあるAWS環境にする」ことを目的にAWS環境の作成に取り組みました。

構成図は以下のようになっています。

冗長化こそしていませんが、よくある3層構造のALB - EC2 - RDSとしています。(冗長化していないのは費用を抑えるため、トレードオフです)

そしてCloudTrail / AWS Config / GuardDuty / Detectiveの4つのサービスはもはやAWS環境では利用しないことはないレベルに不可欠なサービスです。実際インシデントレスポンスにおいてとてつもない働きをします。

地味に大切なのはアプリケーションのログです。フロントにあるALBのログがS3に保存されることももちろんですが、AWS環境上ではEC2は入れ替わるもの、ログは内部だけに保存しておいては入れ替えによって消えてしまいます。

そこでCloudWatchエージェントやfluentdなどでログがCloudWatch LogsやS3に外出しされるのが一般的です。今回もfluentdでNginxのログをS3に保存するように構成しています。

外出しされたS3のログを見るにはAmazon Athenaです。今回のイベントでは事前にCloudTrailとNginxのアクセスログを確認するためのAthenaのテーブルを作成しておき、クエリを書いてログを調査できるよう整えました。

EC2上のアプリからDBへのアクセスにはパスワードを直書きしていません。ちゃんとSecrets Managerに保存しています。AWS環境においてアプリケーションコードに直書きなんて、絶対してはいけませんよ！

インシデントレスポンスする際の手順も、EC2のAMIバックアップを取得し、調査用のインスタンスを建ててバックアップされたEBSを復元しアタッチするなどより現実と同じようにしました。これも地味ですがAWSだと便利にできるところです。

かなりこだわっているので、参加者の方からいい反応をいただけた部分かなーと思います。

対策するならどうする？

解説資料の方でも、対策の手法がいろいろ説明されていますが、AWSに携わるものとしていくつか対策の観点をまとめてみます。

GuardDutyのアラートは見える場所に通知する

今回の環境はGuardDutyやDetectiveが有効ですが、AWSからの連絡があるまでインシデントに気づいていなかった設定です。

せっかくGuardDutyでインシデントを検知したのにそれが見れていないのであれば宝の持ち腐れです。(あとから追うのにも役に立っていますが

必ず通知をいれましょう。私は以下をよく使います。

通知先はメールでなくてもいいので、Slackなど運用上確認できる場所にしましょう。私はメールだと絶対見ません。

IAMの権限レビュー・棚卸しをする

今回はゆるい権限から権限昇格され、最終的にAdministrator権限へ昇格されています。また、途中に強い権限のIAM Userのアクセスキーがハードコードされていることも要因です。

IAMは最小権限の原則をなるべく意識して利用する必要があるでしょう。IAMについては熟知した管理者によるレビューを行うのがいいですが、難しいのが実情です。

検証環境で作成したIAMに一通り処理をさせ、実際にどのようなAPIを実行しているかIAMアクセスアドバイザーを利用して確認することで、最小権限を目指す事が可能です。

危ない権限はSecurity HubのCISベンチマークやAWS基礎セキュリティベストプラクティスなどのセキュリティチェックツールで確認もできます。

AWS Configではより詳細にチェックする権限の定義を行ったカスタムルールにより自動的にチェックすることも、運用上考慮できます。

外部共有する権限設定やリソースポリシーなどがあればIAM Access Analyzerでチェックできます。本番環境のセキュリティ監視を行う場合には、こちらのチェックを常に行うフローにしてもいいかもしれません。

アクセスキーをうっかりGithubなどでパブリックに公開してしまうことを防止するgit-secretsは必ず全ての開発者に導入すべきツールです。

SSHのアクセス経路を作らない

今回は踏み台サーバーを利用してEC2にアクセスしていますが、これも可能であれば無くしてしまうほうがインターネットから攻撃者によってサーバーにアクセスする経路を減らすことができます。

Systems Manager Session Managerを利用すればIAMの権限によりシェルアクセスが可能です。

ALBにWAFをアタッチする

今回の環境では特にWAFを利用していませんでした。AWS環境ではCloudFrontやALBに簡単にアタッチして利用できるAWS WAFが利用できます。

AWS WAFには便利なルールとしてマネージドルールというサードパーティのセキュリティベンダーが定義し運用しているルールがマーケットプレイスから提供されています。これを利用すると、だいぶ簡単に高度なルールが利用可能です。

私のオススメはCSCさんのOWASP Top 10ルールです。

もちろんWAFがあればすべての攻撃を防げるというわけではないです。実際に今回の攻撃もWAFだけでは防げないでしょう。

しかしよくある攻撃に対する防御としてや、攻撃が通るか無差別に確認して回っているものに対しては一定の効果はあるでしょう。また、レートベースでのブロックなど一時的な攻撃の抑制にも利用できます。入れておくだけでも価値は十分あります。

環境を分離する

AWS環境はAWSアカウントを分けることにより一番大きな分離が可能です。

今回一部のユーザーが検証用の設定を本番環境で行っていたことがインシデントの要因の一つになっています。

AWS環境ではリソースレベル、VPCレベル、アカウントレベルなど様々な分離の階層がありますが、AWS Organizationsを始めとしたアカウント管理機能が充実している今では、特にアカウントレベルの分離以外を選択するメリットは低いです。

適切にAWSアカウントレベルで環境を分離しましょう。

アプリケーションコードのセキュリティチェックを行う

今回はアプリケーションの脆弱性を突かれるところから攻撃が始まっています。

きちんと脆弱性診断や管理を行いましょう。

アプリケーションコードのレビューという視点ではCode GuruのSecurity Detectorという機能が最近リリースされました。

残念ながら今回のようなPHPのコードには対応していなかったりしますが、このような観点のチェックも必要です。

まるっと脆弱性診断を外部の会社に依頼するのもいいでしょう。

アプリケーションコードだけでなくインフラストラクチャの脆弱性管理も行ったほうがいいです。最近ではAWS環境ならFuture Vulsがおすすめです。運用に即した管理画面で日本語だしとにかく使いやすいです。SSMと連携して自動パッチ適用も可能です。

まとめ

語りたいことはいっぱいありますが、これぐらいにしておきますｗ

何はともあれ、伝えたいことをいっぱい詰め込んだイベントにすることができたと思います。協力してくれた洲崎さんや後輩、声をかけてくれた中津留さんや場を提供してくれたセキュリティ・キャンプ運営やSecurity-JAWS運営など、様々な方に感謝です。

引き続きAWSとセキュリティの啓蒙を続けていきます。